-
Notifications
You must be signed in to change notification settings - Fork 22
connections.ev3: Improve firmware update. #98
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
- Allow faster flashing of smaller firmwares by erasing only as much as needed. - Work around USB3.0 issues with the EV3 bootloader.
|
Rats, I have a re-freshed clone on linux and wanted to test USB-2 flash. It works, but I am not sure if i use the updated version. I ran in the activated .venv in the git clone on an USB-2 plug: In ERASE_TICKS = 60So looks good, but . . . Bert |
dlech
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
|
@BertLindeman, this is an update for EV3. There were no changes for NXT. |
Hard to read ;-) Thanks |
As noted in the linked commit (coming from pybricks/pybricksdev#98), the hardware version can still be read even when the brick is plugged into a USB 3.0 port. Unforunately, the CRC packets likely cannot be salvaged this way - the CRC request is longer than the CRC response and so the CRC value is overwritten inside the brick.
As noted in the linked commit (coming from pybricks/pybricksdev#98), the hardware version can still be read even when the brick is plugged into a USB 3.0 port. Unforunately, the CRC packets likely cannot be salvaged this way - the CRC request is longer than the CRC response and so the CRC value is overwritten inside the brick.
As noted in the linked commit (coming from pybricks/pybricksdev#98), the hardware version can still be read even when the brick is plugged into a USB 3.0 port. Unforunately, the CRC packets likely cannot be salvaged this way - the CRC request is longer than the CRC response and so the CRC value is overwritten inside the brick.
As noted in the linked commit (coming from pybricks/pybricksdev#98), the hardware version can still be read even when the brick is plugged into a USB 3.0 port. Unforunately, the CRC packets likely cannot be salvaged this way - the CRC request is longer than the CRC response and so the CRC value is overwritten inside the brick.
As noted in the linked commit (coming from pybricks/pybricksdev#98), the EEPROM version can still be read even when the brick is plugged into a USB 3.0 port. Unforunately, the CRC packets likely cannot be salvaged this way - the CRC request is longer than the CRC response and so the CRC value is overwritten inside the brick.
As noted in the linked commit (coming from pybricks/pybricksdev#98), the EEPROM version can still be read even when the brick is plugged into a USB 3.0 port.
Since all of the changes could be done without any low level hacking of the HID API, this is very promising for when we make a web-based version in the future.
Changes have not been tested on a USB2.0 system yet, but there should be no changes.
Tested on a copy of the official firmware (16MiB).
And on a 1.5MiB Pybricks firmware, which now takes about 6 seconds to erase and 6 seconds to install, instead of up to two minutes or more.